Nowadays, when accessing a specified URL (Uniform Resource Locator), a browser obtains the root content of the URL, parses the root content, and establishes a corresponding network request. It is thus clear that in the prior scheme, parsing is not done until a user inputs a web address, and the HTML (Hypertext Markup Language) data content is analyzed after a root URL is downloaded, and then download is done according to an object needing to be rendered. Wherein, DNS resolution needs to be done before the object needing to be rendered is downloaded, however, the time for the DNS resolution may range from a few milliseconds to 100 s, and therefore the time consumed will be relatively long when the prior scheme is employed to access a URL.
In order to solve the problem of the DNS resolution being time consuming, currently, there are several DNS pre-fetching techniques particularly as follows:
1) informing a browser via meta information that it needs to do DNS pre-fetching, for example, <meta http-equiv=“x-dns-prefetch-control” content=“on”/>;
2) using a Link label to forcibly do the DNS pre-fetching, for example, <link rel=“dns-prefetch” href=“http://some-web-site.com”/>;
3) when the address bar is changed, guessing a related suffix, for example, when a user inputs www.sina, guessing such a domain name as www.sina.com, www.sina.org, www.sina.gov, etc. is to be inputted.
However, in the DNS pre-fetching techniques described above, a Link label needs to be specified, and the problem of DNS acceleration cannot be solved for a large number of currently existing webpages. In addition, it is not cost-effective if a webpage is upgraded only for DNS acceleration, and pre-reading for an undesired connection wastes network resources and increases the network traffic cost.